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SELF- ADAPTIVE MULTICAST FILE TRANSFER PROTOCOL 
TECHNICAL FIFLn 

[0001] Embodiments of the invention relate to multicast transfer of data from 
a server device to multiple client devices. More particularly, embodiments of the 
invention relate to use of multicast file transfer protocols in a coordinated 
manner. 

BACKGROUND 

(00021 Currently the Trivial File Transfer Protocol (TFTP) may be used to 
transfer files between devices. In general, TFTP is a transfer protocol that is 
simpler to use than the File Transfer Protocol (FTP), but provides less 
functionality. For example, TFTP does not support user authentication or 
directory visibility, TFTP uses the User Datagram Protocol (UDP) rather than the 
Transmission Control Protocol (TCP). One embodiment of TFTP is desmbed 
formally in Request for Comments (RFC) 1350, Rev. 2, published July 1992. 
[0003] TFTP has been expanded to include.a multicast option as described in 
RFC 2090, published February 1997. Multicast TFTP classifies client devices as 
active clients or passive clients. There is only one active client at a time. The 
active client communicates with a server to download data using a stop-and-wait 
ARQ flow and error control technique to a negotiated group address. Passive 
clients snoop on the download to the active client and capture data destined for 



the group address. When the active client finishes downloading the data, a 
passive client is selected as anew active client 

[0004] The new active client causes the complete file to be downloaded to the 
group address and drops duplicate data padcets. Climts may drop out when all of 
the packets in the file have been received Ne^y added clients may receive the 
complete file as multiple active clients download the complete file. 
[0005) In an error-firee network, all clients may receive the complete file by 
joining the group prior to mitiation of the download. If, however, one or more 
packets are dropped and/or clients join the group after initiation of the download, 
the complete file download must be repeated at least once. The more error prone 
a network due to, for example, varying trafBc patterns, the greater the number of 
times the complete file must be downloaded. Under extreme conditions, each 
passive client may become the active client to complete the download. This may 
result in performance that is worse than standard unicast transfer. Thus, the 
current state of multicast TFTP operation may result in unsatisfactory 
performance. 

BRIEF DESCRIPTION OF TH E DRAWINGS 

Embodiments of the invention are illustrated by way of example, and not 
by way of limitation, in the figures of the accompanying drawings in vMch like 
reference numerals refer to similar elements. 
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Figure 1 is a block diagrm of a netwoik that my 
multiple clients. 

Figure 2 is a flow diagram of one embodiment of a multicast file 
download to one or more active, passive and smart client devices. 

Figure 3 is a block diagram of one embodiment of an electronic system. 

Figure 4 is a state diagram of one embodiment of a role change policy for 
multicast file download to one or more active, passive and smart client devices. 

DETAH JT O DESCRIPTIQM 

[0006] In the following description, numerous specific details aro set forth. 
However, embodiments of the invention may be practiced without these specific 
details. In otiier instances, weU-known circuits, structures and tedmiques have 
not been shown in detail in order not to obscure the understanding of this 
description. 

I0007J In one embodiment of a technique described herein, only missing 
packets axe requested for retransmission after completion of a first download to 
the first active client, if certain network conditions are met In one embodiment, 
in addition to the active and passive clients, a smart client may be supported that 
manages retransmission requests. In one embodiment, a passive client tracks 
packet gaps within a downloaded file. Using at least the packet gap information, 
a passive client may transition to become a "smart client" duU downloads missing 
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datapackets. In one embodiment, the smart cUent may activdy truest the 
packet numbers to the servor. Inoneembodiment»if apacketgapiscontmuous, 
the smart client may use a protocol (e.g., TFTP) having a stream or block size 
option to improve throughput By applying the techniques described herein, the 
retransmission time o a missing packet may be reduced and transmission 
performance may be improved as compared to standard multicast TFTP transfers. 
(0008] In one embodiment, if the downloaded file size is unknown when the 
last packet is received and the size of the lost packets is under a pre-selected 
percentage of the total file size, the receiving passive client may be changed to a 
smartdient After a delay the lost packets may be requested for retransmission 
using a reliable protocol (e.g., TFTP). In one embodiment, if the downloaded file 
size is unknown and the last packet is not received, the receiving pas»ve client 
may restart the downloading session. In one fflibodimen^ if the downloaded file 
size is known and the size of the lost packets is under a pre-selected percentage of 
the total file size, the passive client may be changed to a smart client Aftera 
delay the lost packets may be requested for retransmission usuig a reliable 
protocol (e.g., TFTP). 

[0009] In one embodiment, a file may be downloaded in a pre*boot 
environment The file downloaded may be. for example, a boot image, or other 
data used during a pre-boot phase of an electronic device. 
[0010] Figure 1 is a block diagram of a network that may connect a server to 
multiple clients. Server 100 may be coupled with any number of clients (e.g., 
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140, 1 50, 160) via network 120, which operate accotding to any network 
communication protocol known in the art 

(OOllJ In one embodiment, one client, for example, cUent 160, may operate 
as an active client as defined by the mxdticast TFTP to request download of a file 
firan server 100. Any number of additional cKents, for example, clients 140 and 
1 50, may operate as passive clients as defined by the multicast TFTP to receive 
packets corresponding to the file requested by the active client Upon completion 
of the download by the active client one of the passive clients may become a 
smart client to download missing packets. In the description herein, the t«m 
"packet" refers to any block of data, which can be. for example, a predefined, 
fixed length or variable in length. In one embodiment, a packet is defined by the 
multicast TFTP definitioa In alternate embodiments, other packet sizes may be 
used. 

I0012J In one embodiment a passive client may join the multicast group 
during file download. For these passive cUents, packets transmitted prior to 

joining the multicast group may be received when the missing packets are 

retransmitted to a new active client and/or a smart client 

100131 Performance analysis using possibility theory may show tfiat the 
adaptive cUent technique described herein may result if improved perfonnance 
when packet loss caused by netwoik conditions is considered. To simplify the 
description, the foUowing assumes that aU clients join the downloading session at 
the same time and that possibUity of packet loss is unlfomily distributed. In the 



following analysis, K is the average number of times that each packet is 
transmitted and T is the time for an active client to download the requested file. 
Thus, the time required for the passive client to download the file may be defined 
as: 

[0014] Using a random variable, k, to be the exact number of times each 
packet is transmitted, K can be derived by assuming the probabiliQr, p, that each 
packet is lost or in error: 

Pxobabiliiy[exact-k- actual]^ p^'^x(ji^p) 
From tbc above» random variable k is geometrically distributed. 
[0015] Therefore: 

i8:-//*=|;*xp*-»x(i-.p)«-L 

and 

[0016] Substituting into the above equation yields the average time for a 
passive client to download the file: 
T 

' 1-p 

Using the adaptive client technique described herein, the time for the client to 

download the file is the time spent by the active client plus the time to download 

the missing packets. Ushig M to denote the number of packets in the file: 
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T^''T+pxMxI- = {l+p)xT 
[0017] Therefore, 

Because OSp^l, jr* is shorter than T^. Under real network conditions, the 

probability of packet loss may not be uniformly distributed, which may improve 

the poformance of the technique described herdn. 

I0018J Figure 2 is a flow diagram of one embodiment of a multicast file 
download to one or more active, passive and smart dient devices. In Ute example 
of Figure 2, the cUeot devices are described as downloading a file. The file is 
intended to refer to any size and/or type of data that may be downloaded. TTie file 
may represent any type of data and my be blocks of data diat are not traditionally 
considered complete files. 

I0019J In one embodiment, a multicast file download session may be initiated 
by an active client on behalf of a group that includes die active cUent and one or 
more passive clients, 200. hi one embodiment, tiie protocol that may be used for 
the multicast download is multicast TFTP. The active client may request 
download of die file to a group address through wfaidi tiie active client as well as 
die one or more passive dientsmay receive packets diat cany data corresponding 
to die requested file. 

(0020) In one embodiment, passive clients may track packet gaps widiin die 
requested file, the size of the gaps and/or the continuity of die gaps. Using this 
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infoimation related to the gaps and/or other information, a passive client may 
diange state from a passive cUent to a smart cUent rather Aan possibly becoming 
an active client or remaining a passive client according to the miilticast TFT? 
standards. 

[0021] Downloading of the packets may continue mitil the active client 
completes the download of the file, 210. When the active client has completed 
download of the file, the active client may leave the multicast group download 
session and a new active client may selected according to the multicast TFT? 
protocol, 220. In addition to, or instead of, selecting a new active client 
according to the multicast TFTP protocol, one or more of the passive clients may 
be designated as a smart client, 220, In one embodiment, the following criteria 
may be used for designating a passive client as a smart client In alternate 
embodiments, additional and/or different criteria may also be used Downloading 
of packets may be accomplished using the multicast protocol with a new active 
client and/or with a non-multicast, reliable protocol with a smart client, 230. 
[0022] If the passive cUent has successfully received all of the packets 
corresponding to the requested file, the passive client may leave the downloading 
session. If the file size is unknown and the last packet has been successfiilly 
received by the passive client and the total size of the lost packets is less flian a 
pre-selected amount (e.g., 1 megabyte, 20% of the total file size), then the passive 
client may change state to become a smart client In one embodiment, after a 
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random delay, the smart climt nuy request the missing packets using a reliable 
protocol, for example, non-multicast, or standard TFTP. 
(0023] If the file size is unknown and the last packet has not been 
successfully received by the passive client, then the passive client may remain a 
passive client and continue participating in the multicast download session. If the 
file size is known and the total size of the lost packets is less than a pre-selected 
amount (e.g., 1 megabyte, 20% of die total file size), then the passive client may 
change state to become a smart client In one embodiment, after a random delay, 
the smart client may request the missing packets using a reliable protocol, for 
example, non-multicast, or standard TFTP. 

[0024] Downloading of the packets may continue until the new active client 
completes the download of the file, 240. When the new active client has 
completed the download, if passive clients remain, 250, the active client may 
leave the multicast group download session and a new active client may selected 
according to the multicast TFTP protocol, 220. 

[0025] In one embodiment, the technique of Figure 2 can be implemented as 
instructions executed by an electronic system. The instructions may be stored by 
the electronic device or the instructions can be received by the electronic device 
(e.g., via a network connection). Figure 3 is a block diagram of one embodiment 
of an electronic system. The electronic system illustrated in Figure 3 is intended 
to represent a range of electronic systems, for example, computer systems, 
network access devices, etc. Alternative systems* \sdietber electronic or non- 
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electronic, can include more, fewer and/or different components. The electronic 
system of Figure 3 may rq>re86nt a server device as weU as the one or more client 
devices. 

[0026] Electronic system 300 includes bus 305 or other communication 
device to communicate information, and processor 3 1 0 coipled to bus 305 to 
process information. While electronic system 300 is illustrated with a single 
processor, electronic system 300 can include multiple processors and/or co- 
processras. Electronic system 300 furflier inchides random access memory 
(RAM) or other dynamic storage device 320 (referred to as memory), coupled to 
bus 305 to store information and instructions to be executed by processor 310. 
Memory 320 also can be used to store temporary variables or other intermediate 
information during execution of instructions by processor 3 1 0. 
10027J Electronic system 300 also mdudes read only memory (ROM) and/or 
other static storage device 330 coupled to bus 305 to store static information and 
instructions for processor 310. In one embodiment, static storage device 330 may 
include an embedded firmware agent that may have an interface compliant with 
an Extensile Firmware Interface (EFI) as defined by the EFl Specifications, 
version 1.10, published November 26, 2003, available from Intel Corporation of 
Santa Clara, California. In alternate embodiments, other firmware components 
can also be used. 
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[0028] Data storage device 340 is coiq>ied to bus 305 to store information and 
instructions. Data storage device 340 sudi as a nuignetic disk or optical disc and 
corresponding drive can be coupled to electronic system 300. 
[0029] Electronic system 300 can also be coupled via bus 305 to displ^ 
device 350, such as a cathode ray tube (CRT) or Uquid crystal display (LCD), to 
display infomiation to a user. Alphanumeric input device 360, including 
alphanumeric and other keys» is typically coupled to bus 305 to communicate 
information and command selections to processor 310. Another type of user 
input device is cursor control 370, such as a mouse, a trackball, or cursor 
direction keys to communicate dkection information and command selections to 
processor 310 and to control cursor movement on display 350. Electronic system 
300 further includes networic interface 380 to provide access to a network, such as 
a local area network. Network inter&ce 380 may fbrth^ include one or more 
antennae 385 to provide a wireless network interface according to any protocol 
known in the art 

[0030] Instructions are provided to memory fiom a storage device, such as 
magnetic disk, a read-only memory (ROM) integrated circuit, CD-ROM, DVD. 
via a remote connection (e.g., over a network via network interface 380) that is 
either wired or wireless providing access to one or more electronically-accessible 
media, etc. In alternative embodiments, hard-wired circuitry can be used in place 
of or in combination with software instructions. Thus, execution of sequences of 
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instructions is not limited to any specific combination of hardware circuitry and 
software instructions. 

[0031] An electronically-accessible medium includes any mechanism that 
provides (i.e., stores and/or transmits) content (e.g., computer executable 
instructions) in a form readable by an electronic device (e.g., a computer, a 
personal digital assistant, a cellular telephone). For example, a machine- 
accessible medium includes read only memory (ROM); random access memory 
(RAM); magnetic disk storage media; optical storage media; flash memory 
devices; electrical, optical, acoustical or other form of propagated signals (e.g., 
carrier waves, infrared signals, digital signab); etc. 

[0032] Figure 4 is a state diagram of one embodiment of a role change 

policy for multicast file download to one or more active, passive and smart client 
devices. Initially a potential client device may have a status of "no role** 400 
prior to joining the multicast download group. The potential client device may 
send a request message to a server or other designated device to request 
admittance to the multicast download group. 

[0033] In response to the request message, the responding device may 
transmit an acknowledge message that causes the potential client device to 
become an active client (ACK: ACTIVE) or to become a passive client 
(ACK:PASSIVE). In response to the ACK:ACnVE message the client device 
joins the multicast download group as an active client, 470, and operates as 
described above. In response to the ACK:PASSIVE message the client device 
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joins the multicast download gmup as a passive clioit, 420, and operates as 
described above. 

[0034] In one embodiment, once in the passive client state 420, the client 
remains a passive client until a cunrently active client completes download of the 
file and exits the multicast download group. When the multicast download group 
does not include an active cUent, one of the remaining passive clients is promoted 
to become tiie active client In one embodiment, multiple passive clients m^ 
transmit requests to tiie server or otiier device in an attempt to be named the 
active client. The server or other device may select one of the passive clients to 
be tiie new active client Alternatively, tiie server or otiier device may track tiie 
passive cUents and proactively select one of tiie passive clients to become tiie new 
active client 

[0035] Ifa passive cUent meets the conditions set fortii above to become a 
smart client, tiie passive cUent may become a smart cUent 450. The smart cUent 
may operate in tiie manner described above to request download of lost packets 
using a reliable, non>multicast protocol. 

10036] Reference in the specification to "one embodiment" or "an 
embodimenr means tiiat a particular feature, structure, or characteristic described 
in connection wifli tiie embodiment is included hi at least one embodimmt of tiie 
inventioa The appearances of die phrase "in one embodiment" in various places 
in tiie specification are not necessarily all refenring to tiie same embodiment 
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[0037] While the invention has been described in tenns of several 
embodiments, those skilled in die art will recognize that die invention is not 
limited to the embodiments described, but can be practiced with modification and 
alteration within the spirit and scope of the impended claims. The description is 
thus to be regarded as illustrative instead of limiting. 



14 



